Celestin Apprentice 2/Apprentice-Release2.iso/Information/Programming/Mac Programming FAQ/Mac Programming FAQ 1⁄3

Text File | 1994-12-08 | 29.2 KB | 644 lines | [TEXT/R*ch]

The Public Domain Mac Programming FAQ Answer sheet 2.0
Last update: 29 Nov 94  -Giving Thanks to Steve Jobs-

Changes since 31 Oct 94:
* Standalone code section more complete
* Slight content reformatting
* Minor content updates

IMPORTANT NOTE: No FAQ can substitute for real documentation (some of
which is mentioned in this FAQ) If you ask a question in
comp.sys.mac.programmer which has a good answer in one of the three
important sources, you will probably not get an answer.  (Think
Reference, New Inside Macintosh, Macintosh Technical Notes)

This sheet was started by and largely exists due to the efforts of Jon
Watte, whom you may reach as <[e-mail]>.  Chris Thomas, whom you
may reach as <[e-mail]>, is the current caretaker and
overall responsible person.  If there is anything you find errant,
missing or in need of an update, please send Chris your submission and
he will include it.  All FAQ Answer submissions sent will be considered
to be in the public domain unless stated otherwise (in which case they
will not be included in this FAQ sheet).

LESS IMPORTANT NOTE: This FAQ has recently been reorganized to make it
easier to find and put Qs.  Suggestions and constructive comments are
welcome.

New submissions should be in the form:
"Q: What question should I answer?

A: This one, obviously..."
if you want to definitely see the submission in the next edition.
Otherwise integration may take a bit longer.

This sheet is currently archived on nada.kth.se where you can reach it
using afs as /afs/nada.kth.se/public/ftp/pub/hacks/mac-f aq/CSMP_PD_FAQ
or using anonymous FTP (GIVE YOUR E-MAIL ADDRESS AS PASSWORD!) as
pub/hacks/mac-faq/CSMP_PD_FAQ You can also find it on rtfm.mit.edu unedr
the name macintosh/programming-faq.  But that's not all! It should be
available in the Delphi ICONtact Developer SIG [go com mac dev da info
narrow faq dir], and most likely AOL's Mac Development area [Keyword:
MDV] as well.

This sheet is now posted once a week to the appropriate news groups.  I
have also started adding mail addresses for vendors mentioned in the
FAQ; mail me if you're mentioned and feel neglected!

This sheet is divided into several parts; each of which covers a general
area which often gets asked about in the Internet newsgroup
comp.sys.mac.programmer.  Please download a copy of this answer sheet
and search it before you post to the 'net, to help reduce bandwidth.

There is NO or VERY LIMITED error checking in these code examples, FOR
BREVITY ONLY.  You should make sure you ALWAYS check ALL return codes,
and handle any that you are not prepared to deal with appropriately.

Current topics:
(search for *number* to find a topic quickly)
(topics changed since last FAQ are marked with "++")

 1. Development Tools
    what you need to get started, tool-specific issues
 2. Memory
    handles, large arrays, resource handles
 3. User Interfacing
    menus, windows, events, multitasking
 4. Files
    Mac fopen, wdrefnums, getting the full pathname of files
 5. Imaging
    QuickDraw and how to avoid it
 6. Text
    Text editing packages (#include <limits.h>)
 7. Communications and Networking
    Serial ports, TCP/IP, sockets
 8. Interapplication Communication
    AppleEvents and OSA
 9. Dynamic Linking
    external code resources
10. Compatibility
    gestalt, glue
11. Optional System Software
    11.1. QuickTime
      codec details and the lack thereof
12. Third-Party Solutions
    databases
13. Dessert
    yummies the Macintosh Way
14. Contributors
    whodunnit?

*1* Development and debugging tools for the Macintosh

1.1) Q: What do I need to start writing Macintosh software?

A1:
1. A development environment.
2. A project.
3. Smart Friends (tm).

What I mean by numbers 2 and 3 is:
2. Something that _you_ have a personal interest in getting running.
Something to keep you going through those periods of frustration and
fatigue.  Just working through the exercises in a book won't cut it.

3. People who are at least 2 weeks farther along than you, that can help
you avoid the petty (and not-so-petty) wastes of time that await the
neophyte.  These people should preferably be easy to contact (i.e. a local
phone call) and have the same approximate sleep patterns.

A2: A Mac, a lot of time, and a few hundred $.  Although you can develop
software on a Classic-type machine, it is not to be attempted by the
weak of heart or stressed of time.  If you're doing paid work and/or
work for a company, a Quadra-class machine or Centris 650 or better is
almost a must; remember that your time costs your employer much more
than just your salary.  8 MB is a minimum to run at all comfortably, and
Virtual Memory is not suited for development work.  Similarly; if you
don't have at least 80 MB free on your hard disk you need to buy more
space.

You need a development system such as Think C, CodeWarrior C++, MPW C or
Prograph, you need at least some of the New Inside Mac books (Toolbox
Essentials, Files, Memory come to mind) and a good entry-level
third-party book may help.

Once you are up to speed on the general layout of the Mac and its
toolboxes, you should call APDA and order the monthly developer mailing,
which will give you a CD chock full of documentation, utilities and
system software once a month.  You will also, obviously, need a CD
player; one of which Apple's own CD300 is a very good buy at the time of
writing this.  If you don't have the dough for the monthly mailing
($250/year) you can order a _develop_ subscription; this quarterly
magazine ($30-$50/year) comes with a CD containing most Inside Mac
documentation.  <[e-mail]>

If you don't know how to program, go learn your language of choice
BEFORE attempting a "real" Mac application.  Programming is a discipline
often requiring different thought processes than your normal day job.  A
beginning book, like Lippman: The C++ Primer, or Sydow: Think THINK C
might help (the latter uses the Think C compiler, while the former can
be used with any C++ compiler)

Another tool which many find a must-have is the Think Reference version
2.0.1, containing reference material on the most used parts of the Mac
toolbox with lightning-fast look-up and mostly correct usage hints and
code snippets.  It does not cover the newest system additions, nor the
modern "universal" headers format, though.

1.2) Q: What is the most used Macintosh development system?

A: Out of products on the market, I have no idea; both MPW and Think
products appear to be used.  Lately, CodeWarrior has come out of nowhere
and grabbed a large share of the market visibility because they have the
fastest compiler and they generate PowerPC code as well as 68K code.
Among hobbyists, the Think products from Symantec are most popular
because of the low price, and steep educational discounts, and, of
course, the easily approachable interface! However, now that CodeWarrior
is available at $59-$99 educational price; anything can happen.

The Think C linker only strips dead code on a FILE level basis (and this
is when you turn on "Smart Linking") The MPW linker (of no specified IQ,
as someone so eloquently put it :-) strips dead code by the function, as
does CodeWarrior.  That may be part of the reason the Think C linker is
ten times faster than the MPW linker - but then how do you explain the
CodeWarrior linker, which links like the MPW linker, but at speeds
approaching Think C?

In the beginning, the Mac was programmed using Mc68000 assembly or
Pascal; this was reflected in the Old Inside Mac volumes which only gave
Pascal-style and assembly-style interfaces to the Mac toolbox.  These
days, Apple tells us to use C or even better C++ for developing new
applications, as that will speed up the transition to PowerPC and also
coming cross-platform efforts.  (Language Systems have a Pascal for
PowerPC product now, but I don't know about pricing or quality)

There are also at least two Fortran compilers, at least three SmallTalk
implementations (ObjectWorks, SmallTalk/V and SmallTalkAgents) and
others.  There are ways of stripping SmallTalk apps so they're smaller
and faster as standalone apps than in the environment.

There's also a world-class LISP/CLOS implementation from Apple called
Macintosh Common Lisp.  Recently, Apple announced that DigiTool has
licensed MCL with the intent (among other things) to provide a PowerMac
version and other updates.

Metrowerks have a Pascal and a C and C++ compiler for both 68k and Power
Macs; the package with the three of them is called "CodeWarrior."

CSI has MacForth, of which I only know the name and someone who says
it's pretty good.

There is another good Common Lisp implementation: Procyon Common Lisp.
I don't know if it is actively supported, but Procyon CL is also
available for DOS, OS/2 and Windows (as Allegro CL/PC) and actively
developed.

1.3) Q: Where do I find a public domain C compiler for the Mac.
Is there a GCC for the mac? What about the FSF boycott of Apple
products?

A: There is no really good solution for a "for-free" C development
system for the Mac.  GCC has been ported, but requires the MPW shell and
MPW assembler to run; these have to be bought from APDA.  There is a
standalone port of GCC 1.37 on nic.switch.ch:software/mac/src/think_c.
There was a freely available C compiler called Harvest C, which was
somewhat unstable but usable for smaller programs; it was abandoned by
the original author Eric W Sink because of a lack of time and later
taken up by the TopSoft project.

The FSF boycott of Apple products means they will not talk to you if you
ask them for help in doing a Mac port, and they will not incorporate
your changes into their main code base.  However, they still allow
others to port GNU stuff to the Mac, and it has been done with most of
the application-like GNU programs (bison, flex, perl (not really part of
GNU), ...)

gcc-1.37r14 V1.1 standalone is available for ftp at nic.switch.ch:
software/mac/src/think_c.

A fairly stable port of GCC 2.3.3 to MPW is available for ftp at
atg.apple.com [anyone know the directory?].  A much more solid port of
GCC 1.37 is available for MPW as well.

For those whose main interest is in developing only text based C/C++
programs, using GCC under MacMiNT might be appropriate.  MacMiNT is a
UNIX like operating system ported from the Atari ST which supports many
freely available UNIX utilities like GCC, GDB, make, tcsh, byacc, perl,
and more.  MacMiNT stuff can be found at on nic.switch.ch in
'software/mac/src/macmint'.

1.4) Q: Are there any other free Mac development platforms?

A: Yerk and Mops.  These are object oriented languages based on the old
product Neon which itself was based on Forth.  They are available with
Manuals at oddjob.uchicago.edu (anonymous FTP).

Plus, there's MacGambit, MacScheme, xlisp, and MacMETH which is the
actual ETH (read: Nick Wirth's group) Modula 2, all for free via FTP.
Also available is MacOberon and MacOberon system/3 betas.

And OpenProlog.  And SIOD (Scheme in One Defun) And [mail in more if you
dare [and please do include ftp addresses if ya can]]

1.5) Q: What's the difference between the MPW, Think and CodeWarrior
environments?

A: The main difference is that Think and CodeWarrior are integrated
environments, while MPW provides you with a command-line shell for your
Mac and tools to use in it.  MPW also has a slightly higher systems
demand and a much slower linker.

The good thing about MPW is that you can write scripts and make files to
do anything you want in the way you want it.  Think or CW still don't
have a viable solution to do a build that requires more than one link
operation, or has more than one destination file.

For the MPW environment, there are three source level debuggers; SADE,
SourceBug and Voodoo Monkey.  The latter is an experimental debugger
with support for threads debugging; the middle is bundled with MPW while
SADE has to be bought separately (but is fully scriptable in its own
scripting language)

The Think environments have their own integrated debuggers; the Think
Pascal one has a lot of useful features while the Think C/C++ one is a
little more basic (but is gaining in functionality with each release)
Stepping through source code and looking at variables is generally
faster and easier in Think than the MPW debuggers.

Metrowerks has their own debugger which works like the MPW debuggers; i e
it runs the application standalone and pokes at it from the outside,
while the Think debuggers run the application "wrapped" in a special
environment, making for some subtle interferences with your heap (which
you usually don't notice).  The Metrowerks Debugger is Thread
Manager-saavy.

CodeWarrior is by far the fastest compiler; it can compile to 68k code
on a Power Macintosh for really fast compiles.  Symantec C++ (a k a
"Think C++") is the most complete C++.  MPW has the most powerful
environment.

Any commercial Mac developer should have all three of CodeWarrior, Think
and MPW of whatever language they prefer (Pascal, C or C++), though some
people seem to be able to get by with just CodeWarrior and MPW.  An
ever-increasing number of people get by with just CodeWarrior.

1.6) Q: What is a good low-level debugger for the Mac?

A: MacsBug is freely available for ftp from ftp.apple.com; log in as
user anonymous and give your FULL e-mail address as password.  MacsBug
is your basic monitor-type debugger that takes a few hundred Ks of
memory, and lets you break, step, disassemble, look at the stack etc of
most anything running on your Mac.  Since it's free (it's also on the
developer CDs) and provides most of the functionality you need, this is
a popular choice.

TMON is another debugger which sports a more mac-like interface; it
provides windows and uses the mouse.  It can take as little or much
memory as you want by excluding or including certain areas of
functionality.  A nice touch is the 6502 disassembler that you can use
to de-bug the code the IOP processors run on the Mac IIfx and Quadra
900/950.

Jasik Designs have a debugger called The Debugger which can do both low-
and high-level debugging, with or without source and for all types of
code, application, code resources, everything.  This is the debugger of
choice for many large developers because of its high power and many
features not found anywhere else.  However; newcomers beware! This is
the Lamborghini of debuggers; if you know how to drive it, it is the
fastest way from A to B; if you don't, you'll just end up in the ditch.
As a lady put it: "The man wouldn't know a user interface if it bit him
in the rear."

1.7) Q: Are there any visual developments environments for the
Mac (comparable to Visual C++)?

A: There is no Visual C++ as such.  However, there is a C++
parser/editor called ObjectMaster which provides good browsing and
editing capabilities if you already have a C++ compiler.  Think C++ also
comes with a browser built-in, and you can draw dialogs/windows using
plain old ResEdit, even for your custom view types.

Symantec C++ 7.0 also bundles a view editor/code generator called Visual
Architect; it is fairly complete and has a good level of integration
into the Think Project Manager.

AppMaker is a GUI builder/code generator.  Granted, it's not as nice as
VC++, but it's quite a product in any case.

MarksMan version 3.0 has totally revised TCL templates, and now
generates well-thought-out TCL code.  It can also generate ANSI C code
etc.

Also, Neuron Data has their UI tool called Open Interface, which is
better than VC++ and creates code portable across 35 platforms.
Unfortunately it's $2500 per developer per platform.  There's also two
other cross-platform products called XVT and Galaxy, the former has
gotten flak on UseNet while the latter reportedly is the premier
cross-platform application builder framework; with everything from
styled text to network support.

There is a fully visual, dynamic, object oriented data-flow-driven
programming language for the Mac called Prograph Corporate Programming
Something-or-other (CPX).  It is expensive ($1500) but offers a built-in
database, easy interfaces to existing data bases, very high productivity
in implement-test-debug cycling and also offers cross-platform
capabilities (it comes with a class library which, when your code is
written using it, works under Windows after re-compilation)

SmalltalkAgents comes with a GUI builder, which lets you draw your
interface, and then outputs the code for you.

If you'd rather do Common Lisp, Macintosh Common Lisp offers a Common
Lisp Object System with support for most Mac interface items; you can
edit code while it is running and build stand-alone applications.

However, all of these tools generate rather larger binaries with larger
system demands than a program written in C.  On the other hand; C++
programs require more memory and disk space than programs written in
assembly.  It's a trade-off, and I believe this type of tools is the
wave of the near future.

1.8) Q: What class libraries are there for the Mac?

A: Apart from the libraries mentioned above, there are three contenders:
MacApp, TCL, and PowerPlant.  "Bedrock" will never be released as a
product, although parts of it surface in TCL 2.0 and other parts will be
the base for the OpenDoc Parts Framework.

MacApp is a heavy-duty class library that has tons of features and a
steep learning curve; it runs under MPW with Pascal or C++, and also
under Think Pascal 4.0 A major application written in MacApp is
PhotoShop.

TCL stands for Think Class Library and comes with Think Pascal, C or
C++.  It is a smaller library that still fills most peoples needs; since
Think C implements a subset of C++ (the most important OO concepts such
as virtual functions and inheritance) and the TCL is carefully written
not to take advantage of any C++ features not in Think C, you can use it
with Think C.  A major application written in TCL is Lotus 1-2-3.  (TCL
1.1.3) Starting with Symantec C++ 7.0, Think Class Library 2.0 using
templates and "real" C++ objects is shipping.

PowerPlant is the Metrowerks CodeWarrior offering; it's written by the
guy who designed the Think Class Library, but it has a lot of
differences from the original TCL; for one, it's not a monolithic one
base class framework.  On the other hand, it has some catching up to do
before it reaches the level of MacApp.  It is gaining quite fast on TCL,
but isn't all there yet.


1.9) Q: How should I debug and test my software?

A: Get ahold of, and install, the extensions DoubleTrouble,
DisposeResource and EvenBetterBusError.  They will catch 80% of any
memory related bugs you may have, including many bugs that follow NULL
handles or pointers.

A low-level debugger is required, and while you install it, install the
"leaks" dcmd which will help you catch memory leaks in your application.
All of these tools are available from ftp.apple.com.

1.10) Q: Are there any good Mac programming magazines?

A: One Mac programming magazine I know of is MacTech Magazine (formerly
MacTutor).  It covers a variety of Mac programming topics on various
levels.  Operating independently from Apple, it has a lot of stuff for
the beginning Mac programmer, as well as occasional nuggets for the more
experienced of us.  <[e-mail]>

Another VERY GOOD Magazine is _develop_ which is put out by Apple four
times a year; it comes with a CD containing code for all articles ever
published in _develop_, and a lot of documentation and system software
freebies as well.  $30/year in the US.  <[e-mail]>

1.11) Q: What about protected memory? I'm sick and tired of re-booting
when my application crashes.

A: Write better software!

Or install The Debugger from Jasik Designs, which can provide your
application with write-protection of critical parts of memory.  This may
only work for 030 Macs, though.

Making the Mac OS memory-protected is tricky, because applications expect
to be able to write to low memory, the system heap, temporary memory,
window lists, and even each other's heaps in some interapplication
communication solutions that date back to before AppleEvents and the PPC
Toolbox.

1.12) Q: I have this library written in (Think) Pascal that I want to use
from Think C/Symantec C, but I get link errors/don't know how to do it.
What should I do?

A: Start by writing a .h file describing the interface.  Remember to
declare the Pascal functions "pascal".  Build a library with Think Pascal
and convert it with oConv.

Do you get link errors on symbols defined in your Pascal lib? Check the
capitalisation used.

Do you get errors on symbols like LMUL and LDIV? Those functions are
defined in the Think Pascal library Runtime.lib or uRuntime.lib.  Include
uRuntime.lib and try again.

Do you get link errors on standard symbols like thePort? This is due to
bad capitalization in Symantec's libs.  Run oConv with .v checked.  This
will create a TEXT file with a .v extension.  Open that with a text
editor and correct the capitalization.  Run oConv again, with .v checked
this time too.

Do you still get errors on standard symbols? Are you using Think
C/Symantec C++ version 6 or higher? Then you must open the library (after
converting it) from Think C version *5*, and remove the unit named
%_TOOLBOX.  (If I'm not mistaken, this is the toolbox init unit, which
you won't need anyway.)

*2* Memory

2.1) Q: What is a handle?

A: A handle is a pointer to a pointer to something.  However, it is more
than that; creating a handle by taking the address of one of your own
pointers does NOT create a Handle; the Memory Manager will only deal
properly with Handles that are created using NewHandle or something that
calls it (such as NewRgn or GetResource).

2.2) Q: When do I have to lock a Handle?

A: The contents of a Handle may move, and when it does, the pointer your
handle is pointing to is changed to point to the new address so your
handle is always valid.  The toolbox may call the memory manager to
allocate more memory pretty much anytime you call it (the toolbox) and
when memory is allocated, your handle may move in memory.  Don't
dereference a handle into a pointer (or take the address of a field in a
record a handle is double-pointing to) and then call the toolbox and
expect the pointer to still be valid.  The only way to ensure that the
pointer will still be valid is to call HLock on the handle to lock it.

Use HGetState and HSetState to save & restore the "locked" state of a
handle when you lock it.

2.3) Q: How do I dispose of Handles?

A: DisposeHandle (formerly called DisposHandle) once and ONLY once will
do the trick.  Trying to dispose of an already disposed Handle is an
error.  DoubleTrouble (see above) will catch such bugs when they do
occur.

2.4) Q: What about resources?

A: Calling GetResource returns NULL if the resource is not found or
there is not enough memory, else it returns a handle to the resource.
This handle may be moved or locked like any other handle, but DO NOT
call DisposeHandle to get rid of a resource handle - call
ReleaseResource.  DisposeResource (see above) will catch this kind of
bug.

Remember that AddResource makes a resource handle out of an ordinary
handle, and RmveResource or DetachResource makes an ordinary handle out
of a resource handle.  You cannot call AddResource with a resource
handle; you have to DetachResource it first.

Resource handles are automagically disposed when the resource file they
belong to is closed.

2.5) Q: I'm trying to use a largish array in Think C, but get a "code
overflow" error.  This is valid C, why doesn't it work?

A: The ANSI standard does not guarantee that any structure larger than
32767 bytes be correctly handled.  Because of historical constraints,
the Mac memory model is built around several small blocks of size 32K or
less; these are used both for code and global/static data.  If you want
to use more code or data, you have to turn on "far code" or "far data" -
you still will not get around the restriction of 32K code or data per
compiled file, though.

This is one area where CodeWarrior shines; it works around most such
limitations and it doesn't cost much in performance either!

As opposed to, say, DOS or Windows, however, you can allocate as much
memory as you want (and there is in the machine) and step through it
using ordinary pointers; it's just that global and static data space is
addressed off the A5 register using a 16bit displacement addressing mode
in the 68000 processor.

On the PowerPC, everything is 32bit from the start; that runtime model
is much more like UNIX because it's taken from IBMs AIX.  No limitations
there.

*3* User interaction and You

3.1) Q: How do I read the modifier keys of the keyboard?

A: Just call EventAvail and check the event.modifiers field.
Only works when you are in the foreground. You can also use
GetKeys(), or (as a last resort) check the lo-mem global KeyMap
directly.

3.2) Q: How do I move the mouse cursor to a specific position?

A: Wait! Don't do it! There has to be a better way!

If you feel you HAVE to do it (for a game or VERY special simulation
situation) you can use the Cursor Device Manager documented in the tech
notes on ftp.apple.com.  If that manager is not installed, as it's not
on older Macs, you can use the following code:

you need to have some low-memory globals defined.  they may be defined
in SysEqu.h.

#define MTemp 0x828
#define RawMouse 0x82c
#define CrsrNewCouple 0x8ce

note that CrsrNewCouple is actually a combination of two globals, just
to make our life slightly easier.

the code i use to move the mouse is:

*code*
void
MoveMouseTo ( Point where ) {

   HideCursor ( ) ;
   * ( Point * ) RawMouse = where ;
   * ( Point * ) MTemp = where ;
   * ( short * ) CrsrNewCouple = -1 ;
   ShowCursor ( ) ;
}
*end*

you need to hit a couple more global variables if you want this to work
properly in a multiple-monitor system, but i forget what they are
offhand.  poke through SysEqu.h, and you should be able to figure it out
without a problem.

On the PowerPC, these lo-mem globals may not be available for native
applications; however, all Power Macintoshes implement the Cursor Device
Manager.  All Macs made after March '93 (including Centris 650 and 610)
implement the Cursor Device Manager, in fact.

There is also a file on nada.kth.se:pub/hacks/mac-faq/MoveMouse.c which
shows how to use the Cursor Device Manager, written by an excellent
Apple engineer.  Grab!

3.3) Q: My menus don't show up in the menu bar

A: If your menus are hiearchical, you'll have to install them manually;
GetNewMBar won't do it for you.  See also 15.2.

3.4) Q: When the user selects my menus, I get strange results back; they
seem to have different menu IDs than my menus?

A: The Menu ID as used by the menu manager is NOT the same thing as the
MENU resource ID (used in the MBAR resource and with GetMenu()) When you
create a MENU, ResEdit sets the menu ID to the MENU resource ID, but if
you re-number the resource, you will have to open the menu in ResEdit
and change the menu ID using the "Edit MENU ID" menu item.

3.5) Q: I use GetMenu() to find a menu in the menu bar, and then change
it, but it seems I have a memory leak OR my changes don't "punch
through"

A: GetMenu() is only intended if you don't already have the menu "in
memory." The call you should use almost all the time is GetMHandle()
which gets the handle to a menu in the current menu bar by its menu ID
(not resource id)

3.6) Q: What about pre-emptive multitasking?

A: To the user, the Mac multitasking method, which builds upon each
application calling WaitNextEvent, GetNextEvent or EventAvail every so
often and the Process Manager/MultiFinder switching applications only at
such calls, is at least as good as preemtive multitasking, because the
present system priotitizes user interface responsiveness over everything
else.  The only shortfall about this is formatting floppies, which locks
up the Mac CPU.  This is because the Mac floppy controller is really
stupid, and would happen even if the Mac multitasked preemptively.

There IS "real" pre-emptive multitasking available for use in Mac
applications; the expensive way is buying A/UX 3.0 which can have Mac
applications written as UNIX processes; the cheap way is installing the
Thread Manager which will allow you to create pre-emptive threads.
However, the restrictions on those threads are the same as those on Time
Manager tasks: don't call any function in an unloaded segment, and don't
call QuickDraw or any toolbox call which may move memory (which are most
ToolBox calls; paradoxally, BlockMove is safe :-) as are, surprisingly,
FSRead and FSWrite)

There are several problems with making the Mac OS preemptive; including
apps that draw outside their windows or directly to screen, user dragging
and other issues.  The system is being reimplemented for 8.0 to solve
these problems.

--------------------comp.sys.mac.programmer.info---------------------
comp.sys.mac.programmer.info  is  primarily  for  distributing  FAQs,
tutorials, news, and  similar  documents  related to programming  the
Macintosh.  To post, email [e-mail]
-----------------------about MacTech Magazine----------------------
PO Box 250055, Los Angeles, CA 90025, 310-575-4343, Fax:[phone]
For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
or email to the following @xplain.com : custservice, editorial,
adsales, marketing, accounting, pressreleases, progchallenge,
publisher, info